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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Applicant: Chen, et. al. 
Serial No.: 10/631,947 
Filed: July 30, 2003 

Art Unit: 2616 
Examiner: O'Connor, Brian T. 

Title: METHOD AND SYSTEM FOR CONFIGURING GATEWAYS TO 

FACILITATE A MODEM CONNECTION OVER A PACKET 
NETWORK 



RECEIVED 



OC72 72DQ8 



DECLARATION UNDER 37 C.F.R. § 1-132 

Assistant Commissioner for Patents 
Washington, D.C. 20231-0001 

Dear Assistant Commissioner: 

1, Farshad Farjami, declare as follows: 



1. I am a partner at Farjami & Faijami LLP, an intellectual property law 
fimi, located at 26522 La Alameda Ave., Suite 360, Mission Viejo, California 92691 . 

2. I declare that copies of all documents attached to this declaration, as 
Appendices A, B and C, are true and accurate copies of such documents. 

3. I hereby declare that all statements made herein of my own knowledge are 
u*ue and that all statements made on information and belief are believed to be true; and 
fuilher that these statements were made with the knowledge that willful false statements 
and the like so made are punishable by fine of imprisonment, or both, under Section 1001 
of Title 18 of the United States Code, and that such willful false statements may 
jeopardize the validity of the above-referenced patent application or any patent issuing 
thereon. 
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i:D<m£rev|[.Qa!e^^^^^ 

[AVT] Re: Non-standard RFC 2833 definition of 
ANS, /ANS, ANSam and /ANSam 



• To: Rajesh Kumar <rkumar@cisTO 

' • Subject: [AVTj Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSam and /ANSam 

• Frotn: Henning Schulzrinne <hg.s@cs,coUirnbia.edu> 
. Dale: Sat, 26 Oct 2002 05:02:07 -0400 

• Cc: a.V.t@j.etf,o.rg, .b:!psier@.ci.^^^ .bk!lUllI@!y.':^^^^^^ flemmiiig Andreasen <fandreas@a^^^ 

• List -help : <ma i ho : a v t- req ii est @ i el f. org ?s u bj ec t= h el p> 

• Lishkl: AudioA^ideo Transport Working Group <avt.ietf.org> 

• List-post: <.mai!.iQ^ayL@J.eU^P.rg> 

• List-subscribe: <hUp.s://vv\ywl ,^^^^ 

• List-unsubscribe: <litt[3s;//w\\^wl.,.ie^^^^ 
sujbjeci=iin 

• Organizofion: Columbia University 

• References: <4.3.2.7.2;2()02 1 024 1 54549.0 1 dcb64S@niira-sjc5-8.cisco.com> 
9 Sender: avt-admin@ielf.oig 

• User-agent: MoziHa/5.0 (Windows; U; Windows NT 5.0; en-US; rv: 1 . 1 ) Gecko/20020826 



I've been relying on the expertise of others in describing these. I would (hus value a more concise and V,25-compIianl 
definition of these events. Can you provide text? 

Rajesh Kumar wrote: 
Henning, 

There are certain issues with the definition of the ANS, /ANS, ANSam and /ANSam events that need 
clarification. 

Since at least 450 ms is needed to detect a phase reversal, it is not possible to discriminate between ANS 
and /ANS before 450 ms. However, this resuhs in an unacceptable delay in informing the far end that a 2100 
Wz signal (whatever its variant) has been detected. It takes less than 200 ms to detect that fact that this is a 
2100 Hz signal. 

Question 1: Does RFC 2833 consider it acceptable to send an ANS event (200 ms) and then an /ANS event 
(450 ms), thereby using the /ANS event as an "update" of the ANS event? The same consideration would 
apply to ANSam and /ANSam. Hiis would change how you have defined the.se events in RFC 2833. 

Queston 2: Your use of the "bar" or "slash" is at odds widi that of the ITU V.25. In the ITU 

specification, /ANS is not a separate signal but refers to tlie 2100 Hz cycle during which phase is reversed. 

Thus, the RFC 2833 definition of /ANS corresponds to the following ITU V.25 sequence, where each element 

in the sequence is one cycle: 

ANS, /ANS, ANS, /ANS, ANS, /ANS, ANS 

However, I have no problem with your re-definition of that the "bar" or "slash" means. I only want to point out 
that you say in RFC 2833 that your definition is equivalent to the ITU's, when it isn't. Please look at Figure 3 
of ITU V.25 and add (he applicable clarification in your document. 

Thanks, 



http://www.ietf.org/mail-archive/web/avt/current/msgO 1 686.htm] 1 0/24/2008 
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l AVT] Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSam and /ANSam Page 2 of 2 

Rajesh 

Audio/Video Transport Working Group 
avt@iet f .org 



• Follow-Ups: 

o [AVT] .Siiggejstcd changes to R^^^^ fax/iiiodiw.tpncs 

■ From.: Rajesh Kumar 

o Re; [AVT] NonTStoM^^^^^ 

■ Front: Rajesh Kumar 

• References: 

o lA VT] Noii-stanclard RFC 2833 definition of ANS, /ANS, ANSam and /ANSaiii 

■ From: Rajesh Kumar 

• Prev by Date: Re: lAVT] 2833bis 

• Next by Date: [AVT] MVyPP implementation 

• Previous by thread: | AVT] Non-slandard RFC 2833 deiinilion of ANS, /ANS, ANSam and /ANSam 

• Next by thiead: Re: tAVTl Re: Non,^^ of ANS, /ANS, ANSam and /^ 

• Index(es): 

o 'rhread 



http://www.ietf.org/mail-archive/web/avt/current/msgO 1 686.hlml 1 0/24/2008 
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APPENDIX B 
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[DMePrey][Datc...N^^^^ 

[AVT] Suggested changes to RFC 2833 re: fax/modem 
tones 



• To: Henning Schulzrinne <hgs@cs,colu 

• Subject: I.AVTJ Suggested changes to RFC 2833 re: fax/modem tones 

• From: Rajesh Kumar <rkumar@cisco.com> 
. Date: Wed, 30 Oct 2002 14:08:30 -0800 

• Cc: ayl@ietf,.org 

• In-reply-to: <3DBA5y\0F.7000305@cs.columbia.cdu> 

• List-help: <mfU)iQ;.avl-rcquc^ 

• Lisi'id: Audio/Video Transport Working Group <avi.ietf.org> 

• List-post: <mailto:ayt@ietr 

• List-subscribe: <https;//\yvywLiet^^^^^^ 

• List-unsubscribe: <https.;//www 
Mbjcct3in.subscribe> 

• References: <4.3,2.7,2.2002 1 024 1 54549.0 1 (Icb648 @ mira-sjc5-8.cisco.coni> 

• Sender: ayt-admin®.! 



Henning, 

I have sent you an email a few minutes back with an RFC2833bis enclosure, and the suggested changes marked. In the 
present email, T am listing points from that enclosure for review by the AVT group. The requested changes are: 

Change #1: 1 have changed the definition of the volume field in Section 3.5. You has rightly added Volume? 
columns to the event tables. However, the text in Section 3.5 was wrong in that it said volume was pertinent to 
DTMF only. Volume is important for modem and fax events, and some other categories of events. The new text 
is as follows: 

volume: For DTMF digits and other events representable as tones, 
this field describes the power level of the tone, expressed 
in dBmO after dropping the sign. Power levels range from 0 
to -63 dBmO. The range of valid DTMF is from 0 to -36 dBmO 
(must accept); lower than -55 dBmO must be rejected (TR- 
TSY-000181 , ITU-T Q.24A). Thus, larger values denote lower 
volume. If this field is not defined for an event, 

it is set to zero by the sender and is 

ignored by the receiver If a zero volume is indicated for 

an event for which the volume field is defined, then the receiver 

may reconstruct the volume from interpolation. This allows 
backwards compatibility with RFC 2833, where the volume field 
was specified as undefined for non-DTMF events. 

Change #2: 1 have re-done the definitions of ANS, /ANS, ANSam and /ANSam to indicate that these definitions 
follow semantics that are different from V.25 semantics, and for a good reason. I have also added precautions 
tliat must be followed when detecting and reporting these events. The new definitions are as follows: 

http://www.ietf.org/mail-archive/web/avt/current/msgO 1 709.html 1 0/24/2008 
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I AVT] Suggested changes to RFC 2833 re: fax/modem tones Page 2 of 4 

ANS: «< — definition unchanged »> 

/ANS: This is the same signal as ANS, except that it reverses 
phase at an inteival of 450 +/- 25 ms. It disables both 

echo cancellers and echo suppressors. (In the ITU 
Recommendation V.25 [8], an ANS with a bar on top refers 
to individual phase-reversed cycles rather than to the 

entire signal.) 

ANSam: <« — defmition unchanged »> 

/ANSam: <«'-— definition unchanged »> 

These definitions of the ANS, /ANS, ANSam and /ANSam tones refer to the entire signal. Unlike ITU 
Recommendation V.25 [8]> they do not refer lo individual 450 ms cycles. 

An ANS or ANSam event packet should not be .sent until it is possible to discriminate between an ANS and ANSam 
event. It is however, permissible to send cui ANS or ANSam event packet before phase reversals can be detected. Phase 
reversals, if any. occur at intervals of 450 +/- 25 ms. If a phase reversal is detected after an ANS or ANSam event 
packet is sent, it must be followed by the transmission of an /ANS or /ANSam event packet. 

Change #3: 1 have addecl a new ANS event, ANS2225. 1 have done so per an action item from ITU SG16 to 
request you for this event. This event is used in equipment for the disabled and it must not be confused with the 
other ANS events. Of course^ a new number needs to be allocated to this event. I have not done that. The new 
event is defined as follows: 

ANS2225: This 2225 Hz answer lone is described in ITU Recommendation 

V. 1 8, Annex D for one of several classes of modems operating in the text telephone mode. It is also referred 
to in ITU Recommendation V.22. This is a pure tone with no amplitude modulation and no semantics 
attached lo phase reversals, if there are any. 

Event number Volume???? 

ANS2225 ?? yes 



Explanatory note to Henning: Initially a proprietary "Bell System" method, the 2225 Hz answer tone is now included 
in ITU V.I 8, Annex D which addresses TDD (telecommunications for the disabled) equipment. It is necessary to 
accommodate it for completeness, and for compliance with various legal ordinances. A distinct number must be 
allocated to this event since it must be differentiated from the nonnal, 2100 Hz ANS when reproduced at the far-end 
gateway. 

The following folks have helped me create the suggested changed text: Alex Urquizo, Dan Deliberato, Herb Wildfeur 
and Mehryar Garakani, Bill Foster, Flemming Andreasen and Hisham Abdelhamid. 

Please comment on these recommended changes. 

Thanks, 

Rajesh 

At 05:02 AM 10/26/2002 -0400, Henning Schulzrinne wrote: 

Fve been relying on the expertise of others in describing these. I would thus value a more concise and 
V.25-compliant defmition ofthe.se events. Can you provide text? 



http://www.ietf.org/mail-archive/web/avt/currenl/msgO 1 709.html 1 0/24/2(X)8 
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lAVTJ Sugge<Jted chcUiges to RFC 2833 re: fax/modem tones Page 3 of 4 

Rajesh Kumar wrote: 

Henning, 

There are certain issues with the definition of the ANS, /ANS, ANSam and /ANSam events 
that need clarification. 

Since at least 450 ms is needed to detect a phase reversal, it is not possible to discriminate 
between ANS and /ANS before 450 ms. However, this results in an unacceptable delay in 
informing the far end that a 2100 Hz signal (whatever its variant) has been detected. It lakes 
less than 200 ms to detect that fact that this is a 2100 Hz signal. 

Question 1 : Does RFC 2833 consider it acceptable to send an ANS event (200 ms) and then 
an /ANS event (450 ms), thereby using the /ANS event as an "update" of the ANS event? The 
same consideration would apply to ANSam and /ANSam. This would change how you have 
defined these events in RFC 2833. 

Queston 2: Your use of the "bar" or "slash" is at odds with that of the ITU V.25. In the ITU 
specification, /ANS is not a separate signal but refers to the 2100 Hz cycle during which phase 
is reversed. Thus, the RFC 2833 definition of /ANS corresponds to the following ITU V.25 * 
sequence, where each element in the sequence is one cycle: 

ANS» /ANS, ANS. /ANS, ANS, /ANS, ANS . 
However, J have no problem witli your re-definition of that the "bar" or "slash" means, I only 
want to point out that you say in RFC 2833 that your definition is equivalent to tlie ITU's, 
when it isn't. Please look at Figure 3 of ITU V.25 and add the applicable clarification in your 
document. 
Thanks, 
Rajesh 



Audio/Video Transport Working Group 
avt@ictf.org 

://>y w w ( jetf,org/mai I nian/1 ist i nlo/ay i 



• Follow-Ups: 

o Re: I AVTl Suggested changes to RFC 2833 re: fax/modem tones 

■ From: Henning Schulzrinne 

o Re;. lAYTl Suggested .cliangc.s to RFC 2833_re^ fax/^^^ tones 

■ From: Henning Schulzrinne 

• References: 

o ( AVTj Non-.standard RFC 2833 definition of ANS, /ANS, ANSam and /ANSam 

■ From: Rajesh Kumar 

o [AVT] Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSam and /ANSam 

■ From: Henning Schulzrinne 

• Pj-ev by Date: EEj.IAVTJi?e:„Non,^^^^^^ 

• Next by Date: [A YT]_1-D ACXm^^ 
a Pi-evious by thread:' Re::iAVT]^.!^ 

• Next by thread: Re:.lAyT]JSugge changes tQ RFC.^^^^^ re: .fe/mode^^^^^^ 

• Index(es): 

o IJate 
o Thread 



hitp://www. ietf.org/mail-archive/web/avi/current/m8g01709.html 10/24/2008 
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I AVT] Suggested changes to RFC 2833 re: fax/modem tones Page 4 of 4 



hltp://www.ietf.org/maiI-archive/web/avt/cunent/iTisgO 1 709.html 1 0/24/2008 
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APPENDIX C 



PAGE 29/27 " RCVD AT 10/27/2008 3:52:48 PM CEastem Daylight Time] « 8VR:USPTO-EFXRF-5f14 « DNIS:273B300 ' CSID:949 282 1002 " DURATION (mm-3s):05-1 8 



10/27/2008 MON 12:16 FAX 949 282 1002 FARJAMI & FARJAMI LLP -♦^-^ USPTO 



121026/027 



Re: 1 AVT] Suggested changes to RFC 2833 re: fax/modem tones 



Page I of 2 



[Date Prey] l^^^^^^^ 



Re: [AVT] Suggested changes to RFC 2833 re: 



fax/modem tones 



• To: Rajesh Kuiriar <rkiuTiar@.cisc 

• Subject: Re: [AVT] Suggested changes to RFC 2833 re: fax/nmodem tones 

• F/wn: Henning Schulzrinne <hgs@cs,cplumbia.edii> 

• Date: Mon, 04 Nov 2002 ) 3:5 1 :32 -OSOO 

• Cc: ayL@ietr,.org 

• In-reply-to: <4.3.2.7.2.2()02 ! 024 1 54549.0 1 dcb648@mira-sjc3-8.cisco.com> 

• List-help: <.i.MiJlp.;.aYt:.req^^^ 

• List-id: Audio/Video Transport Working Group <avt,ielf,org> 

• List-post: <maiUo;ayi.@i^ 

• List-siibscrihe: <bttps.://ww>\J^ 

• Ust-unsubscribe: <hUps://w>vw 
§.ubjeci=uiisu 

• References: <4.3.2.7.2.2002 1 024 1 54549.0 1 dcb648@mira-sjc5r8.cisco.com> 
<4.3.2J.2.2002I03013M22/01fed858@mira.^sjc5-8.ciscoxom> 

» Sender: ayt-adnii.n@ielf,gr 

• User-agent: Moziila/5.0 (Windows; U; Windows NT 5. 1 ; en-US; rv: 1 .2b) Gecko/2002 1016 



Fve incorporated your text on ANS and related tones, with minor tweaks. Since I misSsed the -Ox cut-off, a rcvised 
vei*sion of the I-D won't appear until after IETF55, but 

htip;//ww\v.cs,cplumbia.a^ 
hup://wvy{vy,cs,colu.inl;>ia..e^^^^ 

has a preview. 

These definitions ol; the ANS, /ANS, ANSam and /ANSam tones refer to the 
entire signal. Unlike ITU Recommendation V.25 181, they do not refer to 
individual 450 ms cycles - 

An ANS or ANSam event packet should not be sent until it is possible to 
discriminate between an ANS and ANSam event. It is however, permissible 
to send an ANS or ANSam event packet before phase reversals can be 
detected. Phase reversals, if any, occur at intervals of 450 +/- 25 ms . 
If a phase reversal is detected after an ANS or ANSam event packet is 
sent, it must be followed by the transmission of an /ANS or /ANSam event 
packet. 

*Change #3: I have added a new ANS event, ANS2225. I have done so per an 
action item from ITU SG16 to request you for this event. This event is 
used in equipment for the disabled and it must not be confused with the 
other At>JS events. Of course, a new number needs to be allocated to this 
event. I have not done that. The new event is defined as follow.s: 



* 



ANS2225: This 2225 Hz answer tone is described in ITU 



Recommendation 



V.18, Annex D for one of several classes of modems operating in 
the text telephone mode. It is also referred to in ITU 
Recommendation V.22. This is a pure tone v;ith no amplitude 



http://www.ietf.org/mail-archive/web/avt/current/rnsgO 1 72 1 .html 1 0/24/2008 
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Re: [ A VT] Suggested changes to RFC 2833 re: fax/modem tones Page 2 of 2 

modulation and no semantics attached to phase reversals, 

if there are any. 

Event number Volume???? 
ANS2225 ?? yes 

Explanatory note to Henning: Initially a proprietary "Bell System" 
method, the 2225 Hz answer tone is now included in ITU V.18, Annex D 
which addresses TDD (telecommunications for the disabled) equipment. It 
is necessary to accommodate it for completeness, and for compliance with 
various legal ordinances. A distinct number must be allocated to this 
event since it must be differentiated from the normal, 2100 Hz ANS when 
reproduced at the far-end gatev^ay* 

The following folks have helped me create the suggested changed text: 
Alex Urquizo, Dan Deliberate, Herb Wildfeur and Mehryar Garakanl, Bill 
Foster, Flemming Andreasen and Hisham Abdelhamid. 

Please comment on these recommended changes . 

Thanks, 

Ra jesh 



fvudio/Video Transport Working Group 
avt@ietf . org 



• Follow-ups: 

o SY; I AYTJ SiiggMefrchnnges iQ RFC .2833. re:, fax/inodeni 
a From: Guniiar HelLstrom 

• References: 

o I AV T] Npji-slandard RFC 2S33 definition of ANS, /ANS, ANSam and /ANSam 

■ From: Rajesh Kumar 

o l A.VJ i Suggested changes to RFC 2833 rc: fax/modem tones 

■ From: Rajesh Kumar 

• Prev by Date: Re: [AV T] Suggested changes to RFC 2833 re: fax/modem tones 

• Next by Date: Re: [A VT] DrMt^a 

• Previous by thread: Ret XAVlJ Suggeste 

• Next by thread: SY.:iA.VTJ..S.uggested^.d^^^^^ 

• h"idex(es): 

o Date 
o Xliread 
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